Thanks for the PR!

The way I understand it is this

I don't think this is accurate. Temporary queues are created for exactly that purpose. Sender creates a temporary queue in its session, sends a message with a replyTo header with the actual reference to the destination. Then whoever processes the message uses that to reply. As long as the session in the sender is alive, so is the temporary queue. If the queue has been deleted, then the bit that waits for the reply may have died or timed out.

I haven't been able to reproduce the problem reliably so I am not sure what to do for this yet.

Thanks for digging into this! You’re absolutely right about how TemporaryQueue works. What I found in our tests is that JmsMessageSender and JmsTemplate were each opening their own JMS Connection, so the queue created on Connection A could be closed (and deleted) before Connection B tried to reply. By switching both sides to use a single shared ConnectionFactory (via SingleConnectionFactory), they both reuse the same Connection/Session, so the temp queue stays alive until the reply is sent and the flakiness goes away, I think.

What I found in our tests is that JmsMessageSender and JmsTemplate were each opening their own JMS Connection, so the queue created on Connection A could be closed (and deleted) before Connection B tried to reply

Yes but that's a problem in the receiver end of things.

By switching both sides to use a single shared ConnectionFactory (via SingleConnectionFactory), they both reuse the same Connection/Session, so the temp queue stays alive until the reply is sent and the flakiness goes away, I think.

You are probably correct but that's hiding the underlying problem. I'd rather make the test more robust rather than hiding the fact the receiver is closing the conection when it shouldn't have.

Thanks for the PR and the convo, in any case!